Commit patch queue (exported by git-debrebase)

[git-debrebase make-patches: export and commit patches]

Declare fast forward / record previous work

[git-debrebase pseudomerge: quick]

x86/CPUID: surface suitable value in EBX of XSTATE subleaf 1

While the SDM isn't very clear about this, our present behavior make
Linux 5.19 unhappy. As of commit 8ad7e8f69695 ("x86/fpu/xsave: Support
XSAVEC in the kernel") they're using this CPUID output also to size
the compacted area used by XSAVEC. Getting back zero there isn't really
liked, yet for PV that's the default on capable hardware: XSAVES isn't
exposed to PV domains.

Considering that the size reported is that of the compacted save area,
I view Linux'es assumption as appropriate (short of the SDM properly
considering the case). Therefore we need to populate the field also when
only XSAVEC is supported for a guest.

Fixes: 460b9a4b3630 ("x86/xsaves: enable xsaves/xrstors for hvm guest")
Fixes: 8d050ed1097c ("x86: don't expose XSAVES capability to PV guests")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
(cherry picked from commit c3bd0b83ea5b7c0da6542687436042eeea1e7909)

libxl: Fix unneededly rebuilding build.o(pic)

[The symptoms]

When doing a Xen package build for Debian with ccache enabled, we
started getting the following error:

    x86_64-linux-gnu-gcc [...] -o build.o
    /builds/xen-team/debian-xen/debian/output/source_dir/tools/libs/light/../../../tools/libacpi/build.c
    ccache: error: Failed to create temporary file for
    /run/user/0/ccache-tmp/tmp.cpp_stdout.bqxKOP: Permission denied

It turns out to be the case that during the install step of tools (the
install-tools that happens inside the override_dh_auto_install part of
d/rules), the upstream build machinery *again* tries to build this
build.c file, while this has already been done earlier during the actual
build phase.

Since the Debian build process stopped to allow usage of ccache during
the install phase of the process, this issue surfaces.

[The cause]

In tools/libs/light/Makefile, we see the following lines:

    .PHONY: acpi
    acpi:
        $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(CURDIR) DSDT_FILES="$(DSDT_FILES-y)"

    [...]

    $(DSDT_FILES-y) build.o build.opic: acpi

'acpi' is defined as phony target. In the last line, we see that build.o
depdends on acpi.

Also see:
    "4.6 Phony Targets"
    https://www.gnu.org/software/make/manual/make.html#Phony-Targets

A 'normal' target gives make the possibility to track timestamps of a
target file. E.g. compiling foo.c results in foo.o, and as long as foo.c
keeps being 'older' than foo.o, make will think "nothing to do here,
foo.o is up to date, let's move along".

Now, a phony target is some kind of fake target that does not come with
this kind of information, and such behaves like a target that is always
out-of-date. Hence, with a configuration as seen above, it will try to
always unneededly build this build.o and build.opic again.

[Discussion]

Upstream commit e006b2e3be ("libxl: fix libacpi dependency") which
introduced the problem tells us that the purpose of the current
configuration is to make sure the libacpi/ dir is built before we
attempt to work on build.c in here. The changes in there remove an
apparently obsolete line referencing build.o from the libacpi Makefile,
which might mean that in the past this build.* stuff was located in that
part of the code, and was moved into libs/light later.

[The fix]

If it is enough to just have an order-only dependency, we can use an
order-only prerequisite instead, in this place:

    $(DSDT_FILES-y): acpi
    build.o build.opic: | acpi

Also see:
    "4.3 Types of Prerequisites"
    https://www.gnu.org/software/make/manual/make.html#Prerequisite-Types

Now the build machinery will not attempt to unconditionally rebuild
build.o during make install.

[Suggestions for further work]

As can be seen, there's still the $(DSDT_FILES-y) which has the same
acpi dependency and which may lead to similar unwanted side effects.
However, since none of the files in that list have a corresponding build
target in *this* Makefile, it does not trigger the problem for us, and
we leave it alone, for now.

Suggested-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
Fixes: e006b2e3be ("libxl: fix libacpi dependency")

give meaningful error message if qemu device model is unavailable

There's no sense to switch to qemu-xen-traditional device model
if that one is not enabled in the first place. This way we'll
have a chance later to print a message suggesting to install the
missing qemu package if we *actually* need qemu for the device model.

xen/arch/x86: make objdump output user locale agnostic

The objdump output is fed to grep, so make sure it doesn't change with
different user locales and break the grep parsing.
This problem was identified while updating xen in Debian and the fix is
needed for generating reproducible builds in varying environments.

Signed-off-by: Maximilian Engelhardt <maxi@daemonizer.de>

docs: set date to SOURCE_DATE_EPOCH if available

Use the solution described in [1] to replace the call to the 'date'
command with a version that uses SOURCE_DATE_EPOCH if available. This
is needed for reproducible builds.

[1] https://reproducible-builds.org/docs/source-date-epoch/

Signed-off-by: Maximilian Engelhardt <maxi@daemonizer.de>
[Hans van Kranenburg]
Note: this patch is submitted upstream but not committed yet. We
expect that it gets in. Otherwise, we don't wait and already have it
here because I want to have the reproducible build work completed.

tools: don't build/ship xenmon

This is something that hasn't been touched (except for making it Python
3 compatible, which failed) since 2007. Don't build or ship it.

    -# xenmon
      File "/usr/sbin/xenmon", line 680
stop_cmd = "/usr/bin/pkill -INT -z global xenbaked"
    TabError: inconsistent use of tabs and spaces in indentation

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

tools/xl/bash-completion: also complete 'xen'

We have the `xen` alias for xl in Debian, since in the past it was a
command that could execute either xl or xm.

Now, it always does xl, so, complete the same stuff for it as we have
for xl.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
[git-debrebase split: mixed commit: upstream part]

pygrub: Specify -rpath LIBEXEC_LIB when building fsimage.so

If LIBEXEC_LIB is not on the default linker search path, the python
fsimage.so module fails to find libfsimage.so.

Add the relevant directory to the rpath explicitly.

(This situation occurs in the Debian package, where
--with-libexec-libdir is used to put each Xen version's libraries and
utilities in their own directory, to allow them to be coinstalled.)

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

pygrub: Set sys.path

We install libfsimage in a non-standard path for Reasons.
(See debian/rules.)

This patch was originally part of `tools-pygrub-prefix.diff'
(eg commit 51657319be54) and included changes to the Makefile to
change the installation arrangements (we do that part in the rules now
since that is a lot less prone to conflicts when we update) and to
shared library rpath (which is now done in a separate patch).

(Commit message rewritten by Ian Jackson.)

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
squash! pygrub: Set sys.path and rpath

hotplug-common: Do not adjust LD_LIBRARY_PATH

This is in the upstream script because on non-Debian systems, the
default install locations in /usr/local/lib might not be on the linker
path, and as a result the hotplug scripts would break.

A reason we might need it in Debian is our multiple version
coinstallation scheme.  However, the hotplug scripts all call the
utilities via the wrappers, and the binaries are configured to load
from the right place anyway.

This setting is an annoyance because it requires libdir, which is an
arch-specific path but comes from a file we want to put in
xen-utils-common, an arch:all package.

So drop this setting.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

sysconfig.xencommons.in: Strip and debianize

Strip all options that are for stuff we don't ship, which is 1)
xenstored as stubdom and 2) the new options for oom score and open file
descriptor limit, which would not have any effect, because we're
shipping different init scripts... :|

It seems useful to give the user the option to revert to xenstored
instead of the default oxenstored if they really want.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
Acked-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

t/h/L/vif-common.sh: disable handle_iptable

Also see Debian bug #894013. The current attempt at providing
anti-spoofing rules results in a situation that does not have any
effect. Also note that forwarding bridged traffic to iptables is not
enabled by default, and that for openvswitch users it does not make any
sense.

So, stop cluttering the live iptables ruleset.

This functionality seems to be introduced before 2004 and since then it
has never got some additional love.

It would be nice to have a proper discussion upstream about how Xen
could provide some anti mac/ip spoofing in the dom0. It does not seem to
be a trivial thing to do, since it requires having quite some knowledge
about what the domU is allowed to do or not (e.g. a domU can be a
router...).

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

docs/man/xen-vbd-interface.7: Provide properly-formatted NAME section

This manpage was omitted from
   docs/man: Provide properly-formatted NAME sections
because I was previously building with markdown not installed.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

shim: Provide separate install-shim target

When building on a 32-bit userland, the user wants to build 32-bit
tools and a 64-bit hypervisor.  This involves setting XEN_TARGET_ARCH
to different values for the tools build and the hypervisor build.

So the user must invoke the tools build and the hypervisor build
separately.

However, although the shim is done by the tools/firmware Makefile, its
bitness needs to be the same as the hypervisor, not the same as the
tools.  When run with XEN_TARGET_ARCH=x86_32, it it skipped, which is
wrong.

So the user must invoke the shim build separately.  This can be done
with
   make -C tools/firmware/xen-dir XEN_TARGET_ARCH=x86_64

However, tools/firmware/xen-dir has no `install' target.  The
installation of all `firmware' is done in tools/firmware/Makefile.  It
might be possible to fix this, but it is not trivial.  For example,
the definitions of INST_DIR and DEBG_DIR would need to be copied, as
would an appropriate $(INSTALL_DIR) call.

For now, provide an `install-shim' target in tools/firmware/Makefile.

This has to be called from `install' of course.  We can't make it
a dependency of `install' because it might be run before `all' has
completed.  We could make it depend on a `shim' target but such
a target is nearly impossible to write because everything is done by
the inflexible subdir-$@ machinery.

The overally result of this patch is that existing make invocations
work as before.  But additionally, the user can say
  make -C tools/firmware install-shim XEN_TARGET_ARCH=x86_64
to install the shim.  The user must have built it already.
Unlike the build rune, this install-rune is properly conditional
so it is OK to call on ARM.

What a mess.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

config/Tools.mk.in: Respect caller's CONFIG_PV_SHIM

This makes it easier to disable the shim build.  (In Debian we need to
build the shim separately because it needs different compiler flags).

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
[ Hans: adjust from tools/firmware/Makefile to config/Tools.mk.in to
follow changes that happened in 8845155c83 ("pvshim: make PV shim build
selectable from configure") ]
Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

.gitignore: Add configure output which we always delete and regenerate

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

autoconf: Provide libexec_libdir_suffix

This is going to be used to put libfsimage.so into a path containing
the multiarch triplet.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

tools-libfsimage-prefix.diff

\o/

Do not build the instruction emulator

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

Remove static solaris support from pygrub

Patch-Name: tools-pygrub-remove-static-solaris-support

Gbp-Pq: Topic misc
Gbp-Pq: Name tools-pygrub-remove-static-solaris-support

Do not ship COPYING into /usr/include

This is not wanted in Debian.  COPYING ends up in
/usr/share/doc/xen-*copyright.

Patch-Name: tools-include-no-COPYING.diff

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

config-prefix.diff

Patch-Name: config-prefix.diff

Gbp-Pq: Topic prefix-abiname
Gbp-Pq: Name config-prefix.diff

Display Debian package version in hypervisor log

During hypervisor boot, disable the banner and nicely display the xen
version as well as the Maintainer address from debian/control.

For this to work the SOURCE_BASE_DIR variable needs to be set by the
build system to the top directory, i.e. where the debian folder is.

Original patch by Bastian Blank <waldi@debian.org>
Modified by
Hans van Kranenburg <hans@knorrie.org>
Maximilian Engelhardt <maxi@daemonizer.de>

Delete configure output

These autogenerated files are not useful in Debian; dh_autoreconf will
regenerate them.

If this patch does not apply when rebasing, you can simply delete the
files again.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

Delete config.sub and config.guess

dh_autoreconf will provide these back.

If this patch does not apply when rebasing, you can simply delete the
files again.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

debian/changelog: finish 4.16.2-2

debian/control: Add libzstd-dev as Build-Depends

While the code for loading zstd compressed domU kernel images was
already present in the Xen toolstack, we of course also need the build
dependency to actually activate it!

debian/changelog: finish 4.16.2-2

x86/CPUID: surface suitable value in EBX of XSTATE subleaf 1

While the SDM isn't very clear about this, our present behavior make
Linux 5.19 unhappy. As of commit 8ad7e8f69695 ("x86/fpu/xsave: Support
XSAVEC in the kernel") they're using this CPUID output also to size
the compacted area used by XSAVEC. Getting back zero there isn't really
liked, yet for PV that's the default on capable hardware: XSAVES isn't
exposed to PV domains.

Considering that the size reported is that of the compacted save area,
I view Linux'es assumption as appropriate (short of the SDM properly
considering the case). Therefore we need to populate the field also when
only XSAVEC is supported for a guest.

Fixes: 460b9a4b3630 ("x86/xsaves: enable xsaves/xrstors for hvm guest")
Fixes: 8d050ed1097c ("x86: don't expose XSAVES capability to PV guests")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
(cherry picked from commit c3bd0b83ea5b7c0da6542687436042eeea1e7909)

debian/control: Add libzstd-dev as Build-Depends

While the code for loading zstd compressed domU kernel images was
already present in the Xen toolstack, we of course also need the build
dependency to actually activate it!

Declare fast forward / record previous work

[git-debrebase pseudomerge: stitch]

Commit patch queue (exported by git-debrebase)

[git-debrebase make-patches: export and commit patches]

debian/changelog: finish 4.16.2-1

libxl: Fix unneededly rebuilding build.o(pic)

[The symptoms]

When doing a Xen package build for Debian with ccache enabled, we
started getting the following error:

    x86_64-linux-gnu-gcc [...] -o build.o
    /builds/xen-team/debian-xen/debian/output/source_dir/tools/libs/light/../../../tools/libacpi/build.c
    ccache: error: Failed to create temporary file for
    /run/user/0/ccache-tmp/tmp.cpp_stdout.bqxKOP: Permission denied

It turns out to be the case that during the install step of tools (the
install-tools that happens inside the override_dh_auto_install part of
d/rules), the upstream build machinery *again* tries to build this
build.c file, while this has already been done earlier during the actual
build phase.

Since the Debian build process stopped to allow usage of ccache during
the install phase of the process, this issue surfaces.

[The cause]

In tools/libs/light/Makefile, we see the following lines:

    .PHONY: acpi
    acpi:
        $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(CURDIR) DSDT_FILES="$(DSDT_FILES-y)"

    [...]

    $(DSDT_FILES-y) build.o build.opic: acpi

'acpi' is defined as phony target. In the last line, we see that build.o
depdends on acpi.

Also see:
    "4.6 Phony Targets"
    https://www.gnu.org/software/make/manual/make.html#Phony-Targets

A 'normal' target gives make the possibility to track timestamps of a
target file. E.g. compiling foo.c results in foo.o, and as long as foo.c
keeps being 'older' than foo.o, make will think "nothing to do here,
foo.o is up to date, let's move along".

Now, a phony target is some kind of fake target that does not come with
this kind of information, and such behaves like a target that is always
out-of-date. Hence, with a configuration as seen above, it will try to
always unneededly build this build.o and build.opic again.

[Discussion]

Upstream commit e006b2e3be ("libxl: fix libacpi dependency") which
introduced the problem tells us that the purpose of the current
configuration is to make sure the libacpi/ dir is built before we
attempt to work on build.c in here. The changes in there remove an
apparently obsolete line referencing build.o from the libacpi Makefile,
which might mean that in the past this build.* stuff was located in that
part of the code, and was moved into libs/light later.

[The fix]

If it is enough to just have an order-only dependency, we can use an
order-only prerequisite instead, in this place:

    $(DSDT_FILES-y): acpi
    build.o build.opic: | acpi

Also see:
    "4.3 Types of Prerequisites"
    https://www.gnu.org/software/make/manual/make.html#Prerequisite-Types

Now the build machinery will not attempt to unconditionally rebuild
build.o during make install.

[Suggestions for further work]

As can be seen, there's still the $(DSDT_FILES-y) which has the same
acpi dependency and which may lead to similar unwanted side effects.
However, since none of the files in that list have a corresponding build
target in *this* Makefile, it does not trigger the problem for us, and
we leave it alone, for now.

Suggested-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
Fixes: e006b2e3be ("libxl: fix libacpi dependency")

d/*lintian-overrides*: deal with formatting changes

The message output of lintian is changing, and the override lines are
meant to match those messages to silence them.

THEN:
   statically-linked-binary usr/lib/xen-4.16/boot/xen-shim

NOW:
   statically-linked-binary [usr/lib/xen-4.16/boot/xen-shim]

Also see: https://bugs.debian.org/1007002

So, the goal while writing these overrides is not to be as specific as
possible, it's better to be more generic and aim for the lowest chance
to accidentally match (hide) another problem.

For example, for the no-symbols-control-file one in libxenmisc it's the
case for ALL of the so files in the package, so there's not really a
need to put more effort in matching them specifically.

For others, we mostly can just put a * before and after the file names,
so that this will work with old and new lintian versions.

For binary-has-unneeded-section and spelling-error-in-binary, it seems
the order of stuff on the line has changed (filename is now in brackets
and is moved to the beginning of the line), so for them just also use
only the file name with some added *'s... O_o

give meaningful error message if qemu device model is unavailable

There's no sense to switch to qemu-xen-traditional device model
if that one is not enabled in the first place. This way we'll
have a chance later to print a message suggesting to install the
missing qemu package if we *actually* need qemu for the device model.

d/xen-utils-V.lintian-overrides.vsn-in: drop binary-from-other-architecture

This would hit for i386 because it would have amd64 binary stuff inside
the packages. Now that we don't ship anything for i386 any more, this
override is also obsolete.

    I: xen-utils-4.16: unused-override binary-from-other-architecture
    usr/lib/debug/xen-syms-4.16-shim/xen-shim-syms
    [usr/share/lintian/overrides/xen-utils-4.16:9]

xen/arch/x86: make objdump output user locale agnostic

The objdump output is fed to grep, so make sure it doesn't change with
different user locales and break the grep parsing.
This problem was identified while updating xen in Debian and the fix is
needed for generating reproducible builds in varying environments.

Signed-off-by: Maximilian Engelhardt <maxi@daemonizer.de>

d/xenstore-utils.lintian-overrides: drop description-possibly-contains-homepage

While the description still contains a link and the text 'more
information', apparently this one does not hit anymore, as lintian is
telling us:

    I: xenstore-utils: unused-override
    description-possibly-contains-homepage
    https://wiki.xen.org/wiki/XenStore
    [usr/share/lintian/overrides/xenstore-utils:4]

docs: set date to SOURCE_DATE_EPOCH if available

Use the solution described in [1] to replace the call to the 'date'
command with a version that uses SOURCE_DATE_EPOCH if available. This
is needed for reproducible builds.

[1] https://reproducible-builds.org/docs/source-date-epoch/

Signed-off-by: Maximilian Engelhardt <maxi@daemonizer.de>
[Hans van Kranenburg]
Note: this patch is submitted upstream but not committed yet. We
expect that it gets in. Otherwise, we don't wait and already have it
here because I want to have the reproducible build work completed.

d/xen-utils-V.lintian-overrides.vsn-in: drop binary-or-shlib-defines-rpath

Apparently this check is now gone. What remains is an informational
message that says the override is now unused:

    I: xen-utils-4.16: unused-override binary-or-shlib-defines-rpath
    usr/lib/xen-4.16/lib/python/xenfsimage.*.so
    /usr/lib/xen-4.16/lib/x86_64-linux-gnu
    [usr/share/lintian/overrides/xen-utils-4.16:12]

tools: don't build/ship xenmon

This is something that hasn't been touched (except for making it Python
3 compatible, which failed) since 2007. Don't build or ship it.

    -# xenmon
      File "/usr/sbin/xenmon", line 680
stop_cmd = "/usr/bin/pkill -INT -z global xenbaked"
    TabError: inconsistent use of tabs and spaces in indentation

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/*lintian-overrides*: move comments above overrides

The Lintian documentation tells us to put documentation for overrides
above the override line itself.

https://lintian.debian.org/manual/index.html#documenting-overrides

tools/xl/bash-completion: also complete 'xen'

We have the `xen` alias for xl in Debian, since in the past it was a
command that could execute either xl or xm.

Now, it always does xl, so, complete the same stuff for it as we have
for xl.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
[git-debrebase split: mixed commit: upstream part]

d/.../grub.d/xen.cfg: Redirect output when running grub-mkconfig

John E. Krokes noticed that the grub configuration fragment that we ship
outputs text to stdout, which means it will end up being part of the
generated grub configuration. This is wrong, and leads to error messages
during boot like "error: can't find command `Including'."...

Instead, output informational messages about progress to stderr (exactly
like what happens with other messages such as "Generating grub
configuration file ..." or "Found linux image: /boot/vmlinuz-[...]").

For the more prominent message about changing GRUB_DEFAULT as a side
effect, use the grub_warn helper instead.

(Closes: #1016547)

pygrub: Specify -rpath LIBEXEC_LIB when building fsimage.so

If LIBEXEC_LIB is not on the default linker search path, the python
fsimage.so module fails to find libfsimage.so.

Add the relevant directory to the rpath explicitly.

(This situation occurs in the Debian package, where
--with-libexec-libdir is used to put each Xen version's libraries and
utilities in their own directory, to allow them to be coinstalled.)

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

pygrub: Set sys.path

We install libfsimage in a non-standard path for Reasons.
(See debian/rules.)

This patch was originally part of `tools-pygrub-prefix.diff'
(eg commit 51657319be54) and included changes to the Makefile to
change the installation arrangements (we do that part in the rules now
since that is a lot less prone to conflicts when we update) and to
shared library rpath (which is now done in a separate patch).

(Commit message rewritten by Ian Jackson.)

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
squash! pygrub: Set sys.path and rpath

hotplug-common: Do not adjust LD_LIBRARY_PATH

This is in the upstream script because on non-Debian systems, the
default install locations in /usr/local/lib might not be on the linker
path, and as a result the hotplug scripts would break.

A reason we might need it in Debian is our multiple version
coinstallation scheme.  However, the hotplug scripts all call the
utilities via the wrappers, and the binaries are configured to load
from the right place anyway.

This setting is an annoyance because it requires libdir, which is an
arch-specific path but comes from a file we want to put in
xen-utils-common, an arch:all package.

So drop this setting.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

sysconfig.xencommons.in: Strip and debianize

Strip all options that are for stuff we don't ship, which is 1)
xenstored as stubdom and 2) the new options for oom score and open file
descriptor limit, which would not have any effect, because we're
shipping different init scripts... :|

It seems useful to give the user the option to revert to xenstored
instead of the default oxenstored if they really want.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
Acked-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

t/h/L/vif-common.sh: disable handle_iptable

Also see Debian bug #894013. The current attempt at providing
anti-spoofing rules results in a situation that does not have any
effect. Also note that forwarding bridged traffic to iptables is not
enabled by default, and that for openvswitch users it does not make any
sense.

So, stop cluttering the live iptables ruleset.

This functionality seems to be introduced before 2004 and since then it
has never got some additional love.

It would be nice to have a proper discussion upstream about how Xen
could provide some anti mac/ip spoofing in the dom0. It does not seem to
be a trivial thing to do, since it requires having quite some knowledge
about what the domU is allowed to do or not (e.g. a domU can be a
router...).

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

docs/man/xen-vbd-interface.7: Provide properly-formatted NAME section

This manpage was omitted from
   docs/man: Provide properly-formatted NAME sections
because I was previously building with markdown not installed.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

shim: Provide separate install-shim target

When building on a 32-bit userland, the user wants to build 32-bit
tools and a 64-bit hypervisor.  This involves setting XEN_TARGET_ARCH
to different values for the tools build and the hypervisor build.

So the user must invoke the tools build and the hypervisor build
separately.

However, although the shim is done by the tools/firmware Makefile, its
bitness needs to be the same as the hypervisor, not the same as the
tools.  When run with XEN_TARGET_ARCH=x86_32, it it skipped, which is
wrong.

So the user must invoke the shim build separately.  This can be done
with
   make -C tools/firmware/xen-dir XEN_TARGET_ARCH=x86_64

However, tools/firmware/xen-dir has no `install' target.  The
installation of all `firmware' is done in tools/firmware/Makefile.  It
might be possible to fix this, but it is not trivial.  For example,
the definitions of INST_DIR and DEBG_DIR would need to be copied, as
would an appropriate $(INSTALL_DIR) call.

For now, provide an `install-shim' target in tools/firmware/Makefile.

This has to be called from `install' of course.  We can't make it
a dependency of `install' because it might be run before `all' has
completed.  We could make it depend on a `shim' target but such
a target is nearly impossible to write because everything is done by
the inflexible subdir-$@ machinery.

The overally result of this patch is that existing make invocations
work as before.  But additionally, the user can say
  make -C tools/firmware install-shim XEN_TARGET_ARCH=x86_64
to install the shim.  The user must have built it already.
Unlike the build rune, this install-rune is properly conditional
so it is OK to call on ARM.

What a mess.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

config/Tools.mk.in: Respect caller's CONFIG_PV_SHIM

This makes it easier to disable the shim build.  (In Debian we need to
build the shim separately because it needs different compiler flags).

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
[ Hans: adjust from tools/firmware/Makefile to config/Tools.mk.in to
follow changes that happened in 8845155c83 ("pvshim: make PV shim build
selectable from configure") ]
Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

.gitignore: Add configure output which we always delete and regenerate

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

autoconf: Provide libexec_libdir_suffix

This is going to be used to put libfsimage.so into a path containing
the multiarch triplet.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

tools-libfsimage-prefix.diff

\o/

Do not build the instruction emulator

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

Remove static solaris support from pygrub

Patch-Name: tools-pygrub-remove-static-solaris-support

Gbp-Pq: Topic misc
Gbp-Pq: Name tools-pygrub-remove-static-solaris-support

Do not ship COPYING into /usr/include

This is not wanted in Debian.  COPYING ends up in
/usr/share/doc/xen-*copyright.

Patch-Name: tools-include-no-COPYING.diff

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

config-prefix.diff

Patch-Name: config-prefix.diff

Gbp-Pq: Topic prefix-abiname
Gbp-Pq: Name config-prefix.diff

Display Debian package version in hypervisor log

During hypervisor boot, disable the banner and nicely display the xen
version as well as the Maintainer address from debian/control.

For this to work the SOURCE_BASE_DIR variable needs to be set by the
build system to the top directory, i.e. where the debian folder is.

Original patch by Bastian Blank <waldi@debian.org>
Modified by
Hans van Kranenburg <hans@knorrie.org>
Maximilian Engelhardt <maxi@daemonizer.de>

Delete configure output

These autogenerated files are not useful in Debian; dh_autoreconf will
regenerate them.

If this patch does not apply when rebasing, you can simply delete the
files again.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

Delete config.sub and config.guess

dh_autoreconf will provide these back.

If this patch does not apply when rebasing, you can simply delete the
files again.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

Update changelog for new upstream 4.16.2

[git-debrebase changelog: new upstream 4.16.2]

Update to upstream 4.16.2

[git-debrebase anchor: new upstream 4.16.2, merge]

update Xen version to 4.16.2

PCI: simplify (and thus correct) pci_get_pdev{,_by_domain}()

The last "wildcard" use of either function went away with f591755823a7
("IOMMU/PCI: don't let domain cleanup continue when device de-assignment
failed"). Don't allow them to be called this way anymore. Besides
simplifying the code this also fixes two bugs:

1) When seg != -1, the outer loops should have been terminated after the
   first iteration, or else a device with the same BDF but on another
   segment could be found / returned.

Reported-by: Rahul Singh <rahul.singh@arm.com>
2) When seg == -1 calling get_pseg() is bogus. The function (taking a
   u16) would look for segment 0xffff, which might exist. If it exists,
   we might then find / return a wrong device.

In pci_get_pdev_by_domain() also switch from using the per-segment list
to using the per-domain one, with the exception of the hardware domain
(see the code comment there).

While there also constify "pseg" and drop "pdev"'s already previously
unnecessary initializer.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Rahul Singh <rahul.singh@arm.com>
Tested-by: Rahul Singh <rahul.singh@arm.com>
master commit: 8cf6e0738906fc269af40135ed82a07815dd3b9c
master date: 2022-08-12 08:34:33 +0200

build/x86: suppress GNU ld 2.39 warning about RWX load segments

Commit 68f5aac012b9 ("build: suppress future GNU ld warning about RWX
load segments") didn't quite cover all the cases: Apparently I missed
ones in the building of 32-bit helper objects because of only looking at
incremental builds (where those wouldn't normally be re-built). Clone
the workaround there to the specific Makefile in question.

Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 3eb1865ae305772b558757904d81951e31de43de
master date: 2022-08-11 17:45:12 +0200

x86/amd: only call setup_force_cpu_cap for boot CPU

This should only be called for the boot CPU to avoid calling _init code
after it has been unloaded.

Fixes: 062868a5a8b4 ("x86/amd: Work around CLFLUSH ordering on older parts")
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 31b41ce858c8bd5159212d40969f8e0b7124bbf0
master date: 2022-08-11 17:44:26 +0200

x86/spec-ctrl: Enumeration for PBRSB_NO

The PBRSB_NO bit indicates that the CPU is not vulnerable to the Post-Barrier
RSB speculative vulnerability.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: b874e47eb13feb75be3ee7b5dc4ae9c97d80d774
master date: 2022-08-11 16:19:50 +0100

tools/libxl: Replace deprecated -sdl option on QEMU command line

"-sdl" is deprecated upstream since 6695e4c0fd9e ("softmmu/vl:
Deprecate the -sdl and -curses option"), QEMU v6.2, and the option is
removed by 707d93d4abc6 ("ui: Remove deprecated options "-sdl" and
"-curses""), in upcoming QEMU v7.1.

Instead, use "-display sdl", available since 1472a95bab1e ("Introduce
-display argument"), before QEMU v1.0.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Jason Andryuk <jandryuk@gmail.com>
master commit: 41fcb3af8ad6d4c9f65a9d72798e6d18afec55ac
master date: 2022-08-11 11:47:11 +0200

xen/sched: setup dom0 vCPUs affinity only once

Right now, affinity for dom0 vCPUs is setup in two steps. This is a
problem as, at least in Credit2, unit_insert() sees and uses the
"intermediate" affinity, and place the vCPUs on CPUs where they cannot
be run. And this in turn results in boot hangs, if the "dom0_nodes"
parameter is used.

Fix this by setting up the affinity properly once and for all, in
sched_init_vcpu() called by create_vcpu().

Note that, unless a soft-affinity is explicitly specified for dom0 (by
using the relaxed mode of "dom0_nodes") we set it to the default, which
is all CPUs, instead of computing it basing on hard affinity (if any).
This is because hard and soft affinity should be considered as
independent user controlled properties. In fact, if we dor derive dom0's
soft-affinity from its boot-time hard-affinity, such computed value will
continue to be used even if later the user changes the hard-affinity.
And this could result in the vCPUs behaving differently than what the
user wanted and expects.

Fixes: dafd936dddbd ("Make credit2 the default scheduler")
Reported-by: Olaf Hering <ohering@suse.de>
Signed-off-by: Dario Faggioli <dfaggioli@suse.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: c79e4d209be3ed2a6b8e97c35944786ed2a66b94
master date: 2022-08-11 11:46:22 +0200

x86: Expose more MSR_ARCH_CAPS to hwdom

commit e46474278a0e ("x86/intel: Expose MSR_ARCH_CAPS to dom0") started
exposing MSR_ARCH_CAPS to dom0.  More bits in MSR_ARCH_CAPS have since
been defined, but they haven't been exposed.  Update the list to allow
them through.

As one example, this allows a Linux Dom0 to know that it has the
appropriate microcode via FB_CLEAR.  Notably, and with the updated
microcode, this changes dom0's
/sys/devices/system/cpu/vulnerabilities/mmio_stale_data changes from:

  "Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown"

to:

  "Mitigation: Clear CPU buffers; SMT Host state unknown"

This exposes the MMIO Stale Data and Intel Branch History Injection
(BHI) controls as well as the page size change MCE issue bit.

Fixes: commit 2ebe8fe9b7e0 ("x86/spec-ctrl: Enumeration for MMIO Stale Data controls")
Fixes: commit cea9ae062295 ("x86/spec-ctrl: Enumeration for new Intel BHI controls")
Fixes: commit 59e89cdabc71 ("x86/vtx: Disable executable EPT superpages to work around CVE-2018-12207")
Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: e83cd54611fec5b7a539fa1281a14319143490e6
master date: 2022-08-09 16:35:25 +0100

x86/spec-ctrl: Use IST RSB protection for !SVM systems

There is a corner case where a VT-x guest which manages to reliably trigger
non-fatal #MC's could evade the rogue RSB speculation protections that were
supposed to be in place.

This is a lack of defence in depth; Xen does not architecturally execute more
RET than CALL instructions, so an attacker would have to locate a different
gadget (e.g. SpectreRSB) first to execute a transient path of excess RET
instructions.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: e570e8d520ab542d8d35666b95cb3a0125b7b110
master date: 2022-08-05 12:16:24 +0100

xen: arm: Don't use stop_cpu() in halt_this_cpu()

When shutting down (or rebooting) the platform, Xen will call stop_cpu()
on all the CPUs but one. The last CPU will then request the system to
shutdown/restart.

On platform using PSCI, stop_cpu() will call PSCI CPU off. Per the spec
(section 5.5.2 DEN0022D.b), the call could return DENIED if the Trusted
OS is resident on the CPU that is about to be turned off.

As Xen doesn't migrate off the trusted OS (which BTW may not be
migratable), it would be possible to hit the panic().

In the ideal situation, Xen should migrate the trusted OS or make sure
the CPU off is not called. However, when shutting down (or rebooting)
the platform, it is pointless to try to turn off all the CPUs (per
section 5.10.2, it is only required to put the core in a known state).

So solve the problem by open-coding stop_cpu() in halt_this_cpu() and
not call PSCI CPU off.

Signed-off-by: Dmytro Semenets <dmytro_semenets@epam.com>
Acked-by: Julien Grall <jgrall@amazon.com>
(cherry picked from commit ee11f092b515bf3c926eaad053d12d3f2b6e593e)

xen/arm: Advertise workaround 1 if we apply 3

SMCC_WORKAROUND_3 is handling both Spectre v2 and spectre BHB.
So when a guest is asking if we support workaround 1, tell yes if we
apply workaround 3 on exception entry as it handles it.

This will allow guests not supporting Spectre BHB but impacted by
spectre v2 to still handle it correctly.
The modified behaviour is coherent with what the Linux kernel does in
KVM for guests.

While there use ARM_SMCCC_SUCCESS instead of 0 for the return code value
for workaround detection to be coherent with Workaround 2 handling.

Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Acked-by: Julien Grall <jgrall@amazon.com>
(cherry picked from commit af570d1c90f1ed6040d724732f6c582383782e90)

xen/arm: avoid overflow when setting vtimer in context switch

virt_vtimer_save() will calculate the next deadline when the vCPU is
scheduled out. At the moment, Xen will use the following equation:

  virt_timer.cval + virt_time_base.offset - boot_count

The three values are 64-bit and one (cval) is controlled by domain. In
theory, it would be possible that the domain has started a long time
after the system boot. So virt_time_base.offset - boot_count may be a
large numbers.

This means a domain may inadvertently set a cval so the result would
overflow. Consequently, the deadline would be set very far in the
future. This could result to loss of timer interrupts or the vCPU
getting block "forever".

One way to solve the problem, would be to separately
   1) compute when the domain was created in ns
   2) convert cval to ns
   3) Add 1 and 2 together

The first part of the equation never change (the value is set/known at
domain creation). So take the opportunity to store it in domain structure.

Signed-off-by: Jiamei Xie <jiamei.xie@arm.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
(cherry picked from commit 6655eb81092a94e065fdcd0b47a1b1d69dc4e54c)

arm/vgic-v3: fix virq offset in the rank when storing irouter

When vGIC performs irouter registers emulation, to get the target vCPU
via virq conveniently, Xen doesn't store the irouter value directly,
instead it will use the value (affinities) in irouter to calculate the
target vCPU, and then save the target vCPU in irq rank->vcpu[offset].

When vGIC tries to get the target vCPU, it first calculates the target
vCPU index via
  int target = read_atomic(&rank->vcpu[virq & INTERRUPT_RANK_MASK]);
and then it gets the target vCPU via
  v->domain->vcpu[target];

When vGIC tries to store irouter for one virq, the target vCPU index
in the rank is computed as
  offset &= virq & INTERRUPT_RANK_MASK;
finally it gets the target vCPU via
  d->vcpu[read_atomic(&rank->vcpu[offset])];

There is a difference between them while getting the target vCPU index
in the rank. Actually (virq & INTERRUPT_RANK_MASK) would already get
the target vCPU index in the rank, it's wrong to add '&' before '=' when
calculate the offset.

For example, the target vCPU index in the rank should be 6 for virq 38,
but vGIC will get offset=0 when vGIC stores the irouter for this virq,
and finally vGIC will access the wrong target vCPU index in the rank
when updating the irouter.

Fixes: 5d495f4349b5 ("xen/arm: vgic: Optimize the way to store the target vCPU in the rank")
Signed-off-by: Hongda Deng <Hongda.Deng@arm.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
(cherry picked from commit 800f21499e0ec112771ce1e94490ca5811578bc2)

xen/arm: head: Add missing isb after writing to SCTLR_EL2/HSCTLR

Write to SCTLR_EL2/HSCTLR may not be visible until the next context
synchronization. When initializing the CPU, we want the update to take
effect right now. So add an isb afterwards.

Spec references:
    - AArch64: D13.1.2 ARM DDI 0406C.d
    - AArch32 v8: G8.1.2 ARM DDI 0406C.d
    - AArch32 v7: B5.6.3 ARM DDI 0406C.d

Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Michal Orzel <michal.orzel@arm.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
(cherry picked from commit 25424d1a6b7b7e875230aba77c2f044a4883e49a)

xen/arm: traps: Fix reference to invalid erratum ID

The correct erratum ID should be 834220.

Fixes: 0a7ba2936457 ("xen/arm: arm64: Add Cortex-A57 erratum 834220 workaround")
Signed-off-by: Michal Orzel <michal.orzel@arm.com>
Acked-by: Julien Grall <jgrall@amazon.com>
(cherry picked from commit a6f7ed5fc7d5fb5001ef82db99d34bc8a85fc2b6)

xen/arm: Avoid overflow using MIDR_IMPLEMENTOR_MASK

Value of macro MIDR_IMPLEMENTOR_MASK exceeds the range of integer
and can lead to overflow. Currently there is no issue as it is used
in an expression implicitly casted to u32 in MIDR_IS_CPU_MODEL_RANGE.
To avoid possible problems, fix the macro.

Signed-off-by: Michal Orzel <michal.orzel@arm.com>
Link: https://lore.kernel.org/r/20220426070603.56031-1-michal.orzel@arm.com
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Julien Grall <jgrall@amazon.com>
(cherry picked from commit aa1cba100bff84b211f27639bd6efeaf7e701bcc)

xen/arm: p2m don't fall over on FEAT_LPA enabled hw

When we introduced FEAT_LPA to QEMU's -cpu max we discovered older
kernels had a bug where the physical address was copied directly from
ID_AA64MMFR0_EL1.PARange field. The early cpu_init code of Xen commits
the same error by blindly copying across the max supported range.

Unsurprisingly when the page tables aren't set up for these greater
ranges hilarity ensues and the hypervisor crashes fairly early on in
the boot-up sequence. This happens when we write to the control
register in enable_mmu().

Attempt to fix this the same way as the Linux kernel does by gating
PARange to the maximum the hypervisor can handle. I also had to fix up
code in p2m which panics when it sees an "invalid" entry in PARange.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Cc: Richard Henderson <richard.henderson@linaro.org>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Julien Grall <julien@xen.org>
Cc: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Cc: Bertrand Marquis <bertrand.marquis@arm.com>
Tested-by: Luca Fancellu <luca.fancellu@arm.com>
Acked-by: Julien Grall <jgrall@amazon.com>
(cherry picked from commit 407b13a71e324aba76b11e5f66f59ce4a304a088)

arm/its: enable LPIs before mapping the collection table

When Xen boots on the platform that implements the GIC 600, ITS
MAPC_LPI_OFF uncorrectable command error issue is observed.

As per the GIC-600 TRM (Revision: r1p6) MAPC_LPI_OFF command error can
be reported if the MAPC command has tried to map a collection to a core
that does not have LPIs enabled. The definition of GICR.EnableLPIs
also suggests enabling the LPIs before sending any ITS command that
involves LPIs

0b0 LPI support is disabled. Any doorbell interrupt generated as a
    result of a write to a virtual LPI register must be discarded,
    and any ITS translation requests or commands involving LPIs in
    this Redistributor are ignored.

0b1 LPI support is enabled.

To fix the MAPC command error issue, enable the LPIs using
GICR_CTLR.EnableLPIs before mapping the collection table.

gicv3_enable_lpis() is using writel_relaxed(), write to the GICR_CTLR
register may not be visible before gicv3_its_setup_collection() send the
MAPC command. Use wmb() after writel_relaxed() to make sure register
write to enable LPIs is visible.

Signed-off-by: Rahul Singh <rahul.singh@arm.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
(cherry picked from commit 95604873ccf56eb81e96ed0dc8b4dec3278f40ca)

x86/msr: fix X2APIC_LAST

The latest Intel manual now says the X2APIC reserved range is only
0x800 to 0x8ff (NOT 0xbff).
This changed between SDM 68 (Nov 2018) and SDM 69 (Jan 2019).
The AMD manual documents 0x800-0x8ff too.

There are non-X2APIC MSRs in the 0x900-0xbff range now:
e.g. 0x981 is IA32_TME_CAPABILITY, an architectural MSR.

The new MSR in this range appears to have been introduced in Icelake,
so this commit should be backported to Xen versions supporting Icelake.

Signed-off-by: Edwin Török <edvin.torok@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 13316827faadbb4f72ae6c625af9938d8f976f86
master date: 2022-07-27 12:57:10 +0200

tools/libxl: env variable to signal whether disk/nic backend is trusted

Introduce support in libxl for fetching the default backend trusted
option for disk and nic devices.

Users can set LIBXL_{DISK,NIC}_BACKEND_UNTRUSTED environment variable
to notify libxl of whether the backends for disk and nic devices
should be trusted.  Such information is passed into the frontend so it
can take the appropriate measures.

This is part of XSA-403.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

common/memory: Fix ifdefs for ptdom_max_order

In common/memory.c the ifdef code surrounding ptdom_max_order is
using HAS_PASSTHROUGH instead of CONFIG_HAS_PASSTHROUGH, fix the
problem using the correct macro.

Fixes: e0d44c1f9461 ("build: convert HAS_PASSTHROUGH use to Kconfig")
Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 5707470bf3103ebae43697a7ac2faced6cd35f92
master date: 2022-07-26 08:33:46 +0200

x86: also suppress use of MMX insns

Passing -mno-sse alone is not enough: The compiler may still find
(questionable) reasons to use MMX insns. In particular with gcc12 use
of MOVD+PUNPCKLDQ+MOVQ was observed in an apparent attempt to auto-
vectorize the storing of two adjacent zeroes, 32 bits each.

Reported-by: ChrisD <chris@dalessio.org>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 6fe2e39a0243bddba60f83b77b972a5922d25eb8
master date: 2022-07-20 15:48:49 +0200

x86emul: add memory operand low bits checks for ENQCMD{,S}

Already ISE rev 044 added text to this effect; rev 045 further dropped
leftover earlier text indicating the contrary:
- ENQCMD requires the low 32 bits of the memory operand to be clear,
- ENDCMDS requires bits 20...30 of the memory operand to be clear.

Fixes: d27385968741 ("x86emul: support ENQCMD insns")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: d620c66bdbe5510c3bae89be8cc7ca9a2a6cbaba
master date: 2022-07-20 15:46:48 +0200

x86: deal with gcc12 release build issues

While a number of issues we previously had with pre-release gcc12 were
fixed in the final release, we continue to have one issue (with multiple
instances) when doing release builds (i.e. at higher optimization
levels): The compiler takes issue with subtracting (always 1 in our
case) from artifical labels (expressed as array) marking the end of
certain regions. This isn't an unreasonable position to take. Simply
hide the "array-ness" by casting to an integer type. To keep things
looking consistently, apply the same cast also on the respective
expressions dealing with the starting addresses. (Note how
efi_arch_memory_setup()'s l2_table_offset() invocations avoid a similar
issue by already having the necessary casts.) In is_xen_fixed_mfn()
further switch from __pa() to virt_to_maddr() to better match the left
sides of the <= operators.

Reported-by: Charles Arnold <carnold@suse.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 9723507daf2120131410c91980d4e4d9b0d0aa90
master date: 2022-07-19 08:37:29 +0200

x86/spec-ctrl: correct per-guest-type reporting of MD_CLEAR

There are command line controls for this and the default also isn't "always
enable when hardware supports it", which logging should take into account.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: fdbf8bdfebc2ed323c521848f642cc4f6b8cb662
master date: 2022-07-19 08:36:53 +0200

xl: move freemem()'s "credit expired" loop exit

Move the "credit expired" loop exit to the middle of the loop,
immediately after "return true". This way having reached the goal on the
last iteration would be reported as success to the caller, rather than
as "timed out".

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
master commit: d8f8cb8bdd02fad3b6986ae93511f750fa7f7e6a
master date: 2022-07-18 17:48:18 +0200

tools/init-xenstore-domain: fix memory map for PVH stubdom

In case of maxmem != memsize the E820 map of the PVH stubdom is wrong,
as it is missing the RAM above memsize.

Additionally the memory map should only specify the Xen special pages
as reserved.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
master commit: 134d53f577076d4f26091e25762f27cc3c73bf58
master date: 2022-07-12 15:25:20 +0200

xl: relax freemem()'s retry calculation

While in principle possible also under other conditions as long as other
parallel operations potentially consuming memory aren't "locked out", in
particular with IOMMU large page mappings used in Dom0 (for PV when in
strict mode; for PVH when not sharing page tables with HAP) ballooning
out of individual pages can actually lead to less free memory available
afterwards. This is because to split a large page, one or more page
table pages are necessary (one per level that is split).

When rebooting a guest I've observed freemem() to fail: A single page
was required to be ballooned out (presumably because of heap
fragmentation in the hypervisor). This ballooning out of a single page
of course went fast, but freemem() then found that it would require to
balloon out another page. This repeating just another time leads to the
function to signal failure to the caller - without having come anywhere
near the designated 30s that the whole process is allowed to not make
any progress at all.

Convert from a simple retry count to actually calculating elapsed time,
subtracting from an initial credit of 30s. Don't go as far as limiting
the "wait_secs" value passed to libxl_wait_for_memory_target(), though.
While this leads to the overall process now possibly taking longer (if
the previous iteration ended very close to the intended 30s), this
compensates to some degree for the value passed really meaning "allowed
to run for this long without making progress".

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
master commit: e58370df76eacf1f7ca0340e9b96430c77b41a79
master date: 2022-07-12 15:25:00 +0200

x86/mm: correct TLB flush condition in _get_page_type()

When this logic was moved, it was moved across the point where nx is
updated to hold the new type for the page. IOW originally it was
equivalent to using x (and perhaps x would better have been used), but
now it isn't anymore. Switch to using x, which then brings things in
line again with the slightly earlier comment there (now) talking about
transitions _from_ writable.

I have to confess though that I cannot make a direct connection between
the reported observed behavior of guests leaving several pages around
with pending general references and the change here. Repeated testing,
nevertheless, confirms the reported issue is no longer there.

This is CVE-2022-33745 / XSA-408.

Reported-by: Charles Arnold <carnold@suse.com>
Fixes: 8cc5036bc385 ("x86/pv: Fix ABAC cmpxchg() race in _get_page_type()")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: a9949efb288fd6e21bbaf9d5826207c7c41cda27
master date: 2022-07-26 14:54:34 +0200

x86/spec-ctrl: Mitigate Branch Type Confusion when possible

Branch Type Confusion affects AMD/Hygon CPUs on Zen2 and earlier.  To
mitigate, we require SMT safety (STIBP on Zen2, no-SMT on Zen1), and to issue
an IBPB on each entry to Xen, to flush the BTB.

Due to performance concerns, dom0 (which is trusted in most configurations) is
excluded from protections by default.

Therefore:
 * Use STIBP by default on Zen2 too, which now means we want it on by default
   on all hardware supporting STIBP.
 * Break the current IBPB logic out into a new function, extending it with
   IBPB-at-entry logic.
 * Change the existing IBPB-at-ctxt-switch boolean to be tristate, and disable
   it by default when IBPB-at-entry is providing sufficient safety.

If all PV guests on the system are trusted, then it is recommended to boot
with `spec-ctrl=ibpb-entry=no-pv`, as this will provide an additional marginal
perf improvement.

This is part of XSA-407 / CVE-2022-23825.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
(cherry picked from commit d8cb7e0f069e0f106d24941355b59b45a731eabe)

x86/spec-ctrl: Enable Zen2 chickenbit

... as instructed in the Branch Type Confusion whitepaper.

This is part of XSA-407.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
(cherry picked from commit 9deaf2d932f08c16c6b96a1c426e4b1142c0cdbe)

x86/cpuid: Enumeration for BTC_NO

BTC_NO indicates that hardware is not succeptable to Branch Type Confusion.

Zen3 CPUs don't suffer BTC.

This is part of XSA-407.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
(cherry picked from commit 76cb04ad64f3ab9ae785988c40655a71dde9c319)

x86/spec-ctrl: Support IBPB-on-entry

We are going to need this to mitigate Branch Type Confusion on AMD/Hygon CPUs,
but as we've talked about using it in other cases too, arrange to support it
generally.  However, this is also very expensive in some cases, so we're going
to want per-domain controls.

Introduce SCF_ist_ibpb and SCF_entry_ibpb controls, adding them to the IST and
DOM masks as appropriate.  Also introduce X86_FEATURE_IBPB_ENTRY_{PV,HVM} to
to patch the code blocks.

For SVM, the STGI is serialising enough to protect against Spectre-v1 attacks,
so no "else lfence" is necessary.  VT-x will use use the MSR host load list,
so doesn't need any code in the VMExit path.

For the IST path, we can't safely check CPL==0 to skip a flush, as we might
have hit an entry path before it's IBPB.  As IST hitting Xen is rare, flush
irrespective of CPL.  A later path, SCF_ist_sc_msr, provides Spectre-v1
safety.

For the PV paths, we know we're interrupting CPL>0, while for the INTR paths,
we can safely check CPL==0.  Only flush when interrupting guest context.

An "else lfence" is needed for safety, but we want to be able to skip it on
unaffected CPUs, so the block wants to be an alternative, which means the
lfence has to be inline rather than UNLIKELY() (the replacement block doesn't
have displacements fixed up for anything other than the first instruction).

As with SPEC_CTRL_ENTRY_FROM_INTR_IST, %rdx is 0 on entry so rely on this to
shrink the logic marginally.  Update the comments to specify this new
dependency.

This is part of XSA-407.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
(cherry picked from commit 53a570b285694947776d5190f591a0d5b9b18de7)